This is nice work, @vishaangelova.
A couple of things while we wait for reviews from Dev...

Consider making "Providers" part of the headings--like "Configure providers for standalone agent and "Configure providers for Fleet-managed agent." We get better SEO results when key words are adjacent. If one of these topics comes up in search results, the user might be more likely to click if the heading pro to answer their question.

Also some new headings need anchors defined.

You are right… About the titles - would it not be confusing to have “Configure providers…” here as the next second-level heading is “Provider configuration”? Maybe we can rephrase to "Using providers on standalone Elastic Agent” and "Using providers on Fleet-managed Elastic Agent”? WDYT?

About the anchors - I’ve seen people add new content and headings without anchors, probably relying on the heanding’s automatic anchor link for refs - but I guess that may not be a good practice in case the titles change.

In this particular case, I though it would make more sense to link to the second-level heading (## Provider usage by deployment model) if it was ever needed, but that’s an assumption I probably shouldn’t make. I’ll add explicit anchor links.

I know this sentence existed already, but it's really confusing for me. Is this accurate?

Dynamic providers supply multiple key-value mappings. Each mapping represents a separate “item” or resource. {{agent}} merges each mapping with context providers to create a separate configuration for each item.

Hmm, I used Cursor to search for an answer, and I made it check the code in the elastic-agent repo and compare with that. Here’s what it tells me:

“Dynamic providers supply an array of multiple key-value mappings”: This is accurate.

The bullet descriptions are accurate.

What is imprecise/misleading:

“combined with the previous context provider’s key and value mapping” is not how the code conceptualizes it:

• Internally, there is a global context built from all context providers, and a set of dynamic mappings from each dynamic provider (DynamicProviderComm.AddOrUpdate).
• When rendering configurations, the composable controller matches each dynamic mapping to config templates (often using conditions) and creates a separate rendered config per matching mapping, substituting variables like ${docker.container.id} or ${kubernetes.pod.ip}.
• There is no special notion of “the previous” context provider; mappings are merged into the overall state with priorities.

So, the high‑level idea (dynamic providers drive multiple config instances from many items) is true, but the current wording about “previous context provider” is inaccurate and could confuse users.

It also confirmed your suggestion as accurate but I have a slightly more detailed description based on Cursor’s findings (see 016e30e).

Nice!